-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
feat(utils): Use consts rather than getGlobalObject function
#5821
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
dd4ee5a to
5d5b43e
Compare
5d5b43e to
1d15d6e
Compare
getGlobalObjectgetGlobalObject function
|
hmm I wish we could turn on bundle size bot for you - does this give any savings there? Also, when this gets to a good place, could we split this up so we change each package one at a time? |
|
One thing that makes this PR a little bit risky is the fact that the TypeScript compilation doesn't seem to complain about the node.js |
Yeah, I'll split it up because this PR has become huge! |
|
So |
This feels fishy to me. It should be complaining... Is there a place where you see it in a package which doesn't have node types? |
Just double checked and I can stick I suspect it's because |
|
Closing this in favour of multiple smaller PRs |
As discussed here, this PR:
getGlobalObjectwith a constGLOBAL_OBJwhich retains the runtime detection from feat(utils): Modern implementation ofgetGlobalObject#5809WINDOWconst which returnsGLOBAL_OBJbut withtypeof GLOBAL_OBJ & Windowtype.@sentry/browserto ensure stricter typing around the global objectWINDOW_GLOBALto remove any ambiguity?It's worth noting that
@sentry/nodeand downstream node code doesn't seem to make use ofgetGlobalObjectand is already usingglobaland I'm not sure if anything is gained by modifying these.